By Ron Wilson
Integrated System Design
January 3, 2002 (5:38 p.m. EST)

As you've probably already noticed, this issue of ISD is a little different. Not to worry: We aren't changing the structure of the magazine. Every January, as you may remember, ISD publishes our annual Vendor Guide-a listing of tool and services vendors to the SoC community. Normally the Vendor Guide comes packed with your January issue in one of those annoying polyethylene bags. This year, for economic reasons, the publishers chose to bind the Vendor Guide into the magazine. Unfortunately, that entailed reducing the number of engineering articles for this one issue. Sorry about that.

The articles that we did run are built around the theme of SoC integration. The fundamental issues in system-level integration are so familiar as to not need recitation here. But we would like to pause to make a couple of those uninformed observations for which nondesigner editors are justly infamous.

First, there is a definitional problem with the notion of system-level integration. As someone volunteered in a panel discussion earlier this year, the formal definition of system is 'a piece of the whole design, just larger than that for which you are personally responsible." This assessment is both concise and accurate.

The folks at sister publication EE Times reminded me recently that last November marked the 30th anniversary of the Intel 4004-by Intel's reckoning, the first commercial microprocessor. (Don't get the alumni of Four-Phase Systems started on the topic-but that's another editorial.) Anyhow, the 4004 was a small piece of what we now consider to be a microprocessor. The successor 8008 was hailed as a system-level chip in comparison. Today, we refer to SoC devices that include CPU, local memory, interfaces and specialized processing units as system-level chips. Tomorrow, we may reserve the term for chips with all the analog and DRAM on-die as well.

The other point is that as chips approach the system level in contents, the process of chip verification is approaching the process of system verification. Not long ago an executive from Agilent suggested that the only appropriate way to test a single-chip cell phone would be to put it on an RF testbench and send it antenna signals. The problem of verifying such a chip is significantly different from the test problem, of course, but we can already see SoC testing methodologies moving closer and closer to the behavioral level. Object-based verification languages, transaction-based interfaces and heavy use of C++ through programming language interfaces to simulators and emulators are all symptoms.

This is a fundamental departure from the incremental approach of verifying all the individual blocks in an SoC and then verifying the top-level interconnect. And while it has obvious advantages, behavioral stimulation and checking of the design raises some major issues. One is simply simulation capacity. The whole design these days is a lot of gates and, more often than not, a bunch of analog too. Behavioral simulation implies a full-chip model. For practical reasons, that implies a mix of simulation models at different levels of abstraction for all but the simplest transactions. There is an interesting interaction here between rapid advances in tools for stimulating and checking a model and the simulation tools themselves. Can the simulators keep up?

http://www.isdmag.com

© 2002 CMP Media LLC.
1/1/02, Issue # 14151, page 4.